firefox: Add patch to fix AES GCM IV bit size #87708
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Regression introduced by bce5268.
The bit size of the initialisation vector for AES GCM has been introduced in NSS version 3.52 in the
CK_GCM_PARMS
struct via the ulIvBits field.Unfortunately, Firefox 68.8.0 and 76.0 do not set this field and thus it gets initialised to zero, which in turn causes IV generation to fail.
I found out about this because WebRTC stopped working after updating to NSS 3.52 and so I started bisecting.
Since there wasn't an obvious error in Firefox hinting towards NSS but instead just the video stream ended up as a "null" stream, I didn't suspect the NSS update to be the culprit at first. So I verified a few times and then also started bisecting the actual commit in NSS that
caused the issue.
This turned out to be the problematic change:
https://phabricator.services.mozilla.com/D63241
Since the test I've used was a bit flaky, I still didn't believe the result of the bisect to be accurate, but after running the test several times leading same results I dug through the above change line by line to get more clues.
It fortunately didn't take that long to stumble upon the ulIvBits change (which is actually documented in the NSS 3.52 release notes, but I managed to blatantly ignore it for some reason) and started checking the Firefox source tree for changes regarding that field.
Initialisation of that new field has been introduced in preparation for the 76 release, but subsequently got reverted prior to the release, because Firefox 76 is expected to be shipped with NSS 3.51, which didn't have the ulIvBits field.
The patch I'm adding here is just a reintroduction of that change, because we're using NSS 3.52. Not initialising that field will break WebRTC and WebCrypto, which I think the former seems to gain in
popularity these days ;-)
Tested the change against the mentioned VM test and also by testing manually using Jitsi Meet and Nextcloud Talk.